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Removal of the 30-Second Delay When Hosts Come Up 


The IMP currently delays accepting input from a Host for 30 
seconds after the Host has come up. This delay serves to allow 
the fact that the Host is up to propagate through the network. 
The fundamental problem is that a Host must not be permitted 
to communicate with a second Host until the second Host 
(actually its IMP) has been made aware that the first Host is 
up. Otherwise, one Host may come up and send a "hello" 
message to another Host, whose reply is discarded by the IMP 
because it is for a dead destination. 


All this reasoning is based on a dead destination de- 
tection mechanism at the source IMP. The 30-second delay is 
based on the worst-case propagation delay for routing information 
in the network, so that every potential source IMP can update 
its host up/down table. There are several drawbacks to this 
scheme: 


1. Hosts should not have to wait the worst-case time 
of 30 seconds to send to Hosts at their IMP or 
nearby in the network. 


2. The operation of half-duplex interfaces is made 
even more complicated because of the startup delay. 


3. The timeout period of 30 seconds is really a 
function of network topology and we would like to 
be able to change it when necessary as the network 
expands. 


We propose to eliminate the 30-second delay altogether. 


The IMP subnetwork will detect messages for a dead Host at the 
destination IMP instead of at the source IMP. There is no delay 
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involved for an IMP to sense when its own Hosts come up, so 
that it can always make the correct decision about whether to 
give a message to one of its Hosts or to return a destination 
dead message to the source Host. Under this new scheme, when- 
ever the IMP’s ready line is up it is ready to accept input 
from its Hosts without delay. Several comments on this change 
should be noted: 


1. No change to Host software should be necessitated 
by this change. The Host may attempt to send a 
message to the IMP as soon as it brings its 
ready line up, or it may delay for a long time. In 
either case, the IMP will take the message. As 
before, as soon as the Host has brought up its 
ready line, it must accept messages from the IMP. 


2. The Hosts may wish to remove any delays _they_ have 
programmed into their startup routines, since 
such delays are no longer necessary. 


3. Destination dead messages will be returned as 
before with two differences. There will be more 
delay between the receipt of the message at the 
IMP and the return of the dead destination message 
because it must travel through the network. For 
the same reason, if many messages are sent to 
dead Hosts, the dead destination messages may come 
back out of order. 


The Host personnel responsible for the IMP software at 
each site should check that this proposed change will not ad- 
versely affect them. If no adverse comments are received, 
this change will go into effect on Tuesday morning, December 
12 at the regular IMP software release time. 
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